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EXTENSIBLE MODEL NETWORK REPRESENTATION 
SYSTEM FOR PROCESS PLANNING 

CROSS REFERENCE TO RELATED APPLICATIONS : 

This application is related to the following 
applications which are incorporated herein by reference: 
U.S. Application Serial No. OS / So^tHS U filed 

&2 /ifr //^9~7 , and entitled SYSTEM AND 

METHOD FOR MANAGING ATP <ALb oi ney D o cket No . 
^ 020431. Q13& > . 

U.S. Application Serial No. 6^^0^)223 , filed 

OHfi'b/ , and entitled INTERACTIVE 

REPORT GENERATION SYSTEM AND METHOD OF OPERATION 
(■ Afttorncy -Poe keL Nu. 020431.0137). - — » 
U.S. Application Serial No. Affrl^M^ , filed 

^6 f\t* I M , and entitled STRATEGY DRIVEN 



PLANNING SYSTEM AND METHOD OF rtPffpa^PTnw ~ pe**4***xxx*y pfwilr^vt- 
No , 020431 , 0138) ■ - * 

TECHNICAL FIELD OF THE INVENTION 

This invention relates in general to the field of 
process planning. More particularly , the invention 
relates to an extensible model system architecture for 
integrated material and capacity planning, and integrated 
factory and distribution planning. 
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BACKGROUND OF THE INVENTION 

Manufacturers and distributors commit to time 
critical production and delivery of goods as a regular 
part of their business. Often, the manufacturing and 
5 distribution process is complex, having many different 

material and capacity constraints that simultaneously 
affect the implementation of the process. Due to the 
complexity of the processes, many different software 
tools have been developed to help manufacturers and 
10 distributors plan. Most such tools only address narrow 

parts of the overall planning process. Several unrelated 
tools may be required to fully plan a process. 
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SUMMARY OF THE INVENTION 

The present invention provides an extensible model 
architecture for process planning that eliminates or 
reduces problems with prior systems. 
5 More particularly, in one embodiment, the present 

invention provides a computer software system for 
modeling a process capability on a computer. The 
computer software system comprises an operation model 
type for defining a plurality of operation models. Each 
10 operation model represents an activity that can be 

performed by a process. A resource model type is for 
defining a plurality of resource models. Each resource 
model represents capacity available for use in performing 
an activity and rules for allocating capacity to the 
15 activity. A buffer model type is for defining a 

yf. plurality of buffer models. Each buffer model represents 

gi rules for controlling a flow of material between 

1 activities. The operation model type, buffer model type, 

Q 

and resource model type each comprise a plurality of 
O 20 fields defining attributes. The plurality of fields 

includes a plurality of extension selector fields that 
each allow a user to specify one of a plurality of 
extensions that augment a model with additional fields 
and semantics. The model type specifies a base set of 
25 fields and semantics which includes fields that select 

extensions that specify additional fields and semantics 
that can be added to a particular model. The presence of 
a field in a model is dependent upon a value of another 
field in the model. Defined operation models, buffer 
30 models, and resource models are stored as nodes in an 

interrelated process network model. The process network 
model is formed by a plurality of operation models each 
specifying buffer models from which material is consumed 
and buffer models to which material is supplied and 
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specifying resource models having capacity used in 
performing the activity specified by the operation model. 
In this manner, both material and capacity usage are 
simultaneously represented along with timing constraints 
between activities. 

According to the present invention, to model a plan 
for a process, a plan network model is constructed upon 
the process network model. An operation-plan model type 
is used to define a plurality of operation-plan models. 
Each operation-plan model represents a plan for 
performing an activity represented by an operation model. 
A resource-plan model type is used to define a plurality 
of resource-plan models. Each resource-plan model 
represents a planned usage of capacity represented by a 
resource model. A buffer-plan model type is used to 
define a plurality of buffer-plan models. Each buffer- 
plan model represents a planned flow of material 
represented by a buffer model. A plan network model is 
formed by a plurality of operation-plan models each 
specifying resource-plan models planned to be used in 
performing the activity specified by the operation-plan. 
The nodes of the plan network model are built upon and 
refer to the nodes of the process network model. 
According to the present invention, the process network 
model represents possibilities of what can be done, and 
the plan network model represents that which is planned 
to be done. 

According to one aspect of the present invention, 
each model type has one or more extension points that may 
be used to extend the basic model type in order to 
support the information needed to create the user defined 
models. For each extension point, a user may select an 
appropriate extension to model a particular aspect of the 
user's system. 
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According to another aspect of the present 
invention, several elements of a user's process model may 
share data in a hierarchical fashion referred to as 
families. A child model inherits all of the data of the 
5 parent model unless it is specifically overridden by a 

designation in the child model. A software system 
implementing the teachings of the present invention may 
provide for date effectivity of models using the families 
feature. 

10 It is a technical advantage of the present invention 

to use extensions to define the elements of the process 
p or system being modeled because it reduces the amount of 

*0 data that needs to be stored in a memory device without 

D 

in reducing modeling power. According to the teachings of 

Si 15 the present invention, data for each element of the 

D 

r~; modeled process is stored at a node of a user model or 

%T\ process network model. The data stored at a node 

comprises only the data for the fields corresponding to 
the extensions that are selected by the user. The system 
D 20 does not store a zero quantity for each field not chosen 

EE: 

2 by the user. Therefore, the use of extensions reduces 

W the size requirement for a memory device in a system 

implementing the present invention. 

The software system of the present invention can be, 
25 but not necessarily, implemented using object oriented 

programming. Use of object oriented programming supports 
simultaneous use of multiple types of models for the 
different elements of the planning problem. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

For a more complete understanding of the present 
invention and advantages thereof, reference is now made 
to the following description taken in conjunction with 
the accompanying drawings in which like reference numbers 
indicate like features and wherein: 

FIGURE 1 is a graphical representation of a portion 
of a process network model implementing an extensible 
model architecture for use in planning a process 
according to the teachings of the present invention; 

FIGURE 2 is a graphical representation of a plan 
network model implementing an extensible model 
architecture for use in planning a process according to 
the teachings of the present invention; and 

FIGURE 3 is a graphical representation of a family 
of resource models in a process network model 
implementing inheritance ; 

FIGURE 4 is a graphical representation of a family 
of resource models in a process network model 
implementing date effectivity. 
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DETAILED DESCRIPTION OF THE INVENTION 

In one embodiment, the present invention provides a 
software system for modeling various processes. For 
example, the software system may model a manufacturing 
process used to produce a particular item or product. 
The software system may also be used to model a product 
distribution channel, a supply chain, or an order 
fulfillment process. 

According to the present invention, a process is 
modeled using three primary model types: an operation 
model type, a buffer model type, and a resource model 
type. A plan for that process is similarly modeled with 
three associated primary model types: the operation-plan, 
buffer-plan, and resource-plan. A user uses a model type 
as a template to create a model. For example, a buffer 
model type is used to create a model of a buffer. Each 
of these user defined models is stored as a node in a 
process network model of a user's process. 

The model types used by the system are extensible in 
that each model type may have one or more extension 
points that allow a user to customize the model to 
represent the user's process. For each extension point, 
a user may choose from numerous extensions the one that 
is best suited to define a particular aspect of the 
user's system or process. Each model type has a list of 
predefined extensions from which the user may choose. 
Each extension defines fields that extend the data and 
meaning associated with a model type. These extensions 
and fields define the way in which the model types 
interact. Each user defined model is defined by a model 
type, one extension for each extension point of the model 
tYP e # and data for each field of the model type and 
extensions. Possible features of each of the model types 
are discussed in detail below. 
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The Operation Model Typ e 

The operation model type may be used to create 
operation models which represent activities that can be 
5 performed. As used herein, "operation model type" means 

a general model for activities that may be modeled by the 
software. "Operation node" and "operation model" are 
used interchangeably to represent a specific operation 
defined by a user using the operation model type. This 
10 convention is also used with respect to buffers and 

resources. 

^ An operation model type models a process, activity, 

5 or action that transforms or moves items resulting in a 

flow into, out of or between buffers. Operations may 
15 require resources with specific skills. Those resources 

p model the capacity to perform operations. Buffers model 

jjj the flow of items that result from operations. 

Operations model the activity . 

Activities may include transportation, storage, 
£3 20 picking, receiving, testing, assembling, packaging, 

manufacturing, designing, setup, maintenance, and other 
actions. An operation can use any number of resources, 
with different run times, and with staggered start and 
end dates. Thus, a single activity or a whole series of 
25 activities can be modeled with a single operation. This 

is important for having sufficient flexibility to model 
diverse activities in different manufacturers, even 
within a single supply chain. 

The modeling needs of these varied activities can be 
30 very different. To support those variations, the 
operation model can be extended via a 'process' 
extension. Different extensions each can add different 
fields to the operation model. A simple process 
extension may add a single field such as a fixed amount 
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of time that the operation runs, A more complex process 
extension may add a fixed time and a per-unit time that 
is computed proportional to the number of units that 
operation performed. A much more complex process 
5 extension may add a field that is a list of other 

operations which are performed in sequence in order to 
perform this operation. 

Thus, unlike traditional manufacturing software that 
separate routings and operations, the present invention 
10 allows a routing to be modeled as simply a particular 

kind of operation - an operation that consists of other 
operations that are run in sequence. The relationships 
y3 between those sub-operations can be different depending 

y upon the chosen extension. So, an operation can model a 

Sj 15 simple routing (a sequence of operations allowed to 

S spread) , a flow routing (a sequence of operations which 

\ 3 I ' 

p must flow into one another) , a set of operations that can 

£ be run at the same time, alternates (a set of alternate 

% operations) , and other combinations. 

p 20 Further, since routings are modeled as operations, 

L J[ they can be put in other operations. For example, a 

simple routing operation may consist of five operations. 
One of those five may be an alternates operation, which 
consists of three possible operations. One of those 
25 possibilities may itself by a simple routing operation 

consisting of three operations. Thus, depending upon 
which alternate is chosen, there may be five or seven 
operations to perform. 

An operation can also model simply the bill-of- 
30 materials for an item (operations that just model the 

transform of items, but do not model the capacity 
required to do that) . Similarly, an operation can model 
simply the bill-of-distribution for an item (operations 
that just model the movement of items between buffers, 
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but do not model the capacity required to do so) . Other 
operations can then combine the bill-of-materials or 
bill-of-distribution operations with operations that 
properly consume capacity. Such separation is common in 
older manufacturing databases. 

Some operation specifications can define multiple 
operations. For example, some manufacturing software 
defines operations such that resources can be loaded just 
during portions of operation time. For ease of 
interfacing such packages or databases, process 
extensions can be provided with the identical 
specification. That process generates a routing-like 
operation containing auto-generated sub-operations that 
contain the different phased resource loadings. 

An advantage of the operations model type design is 
simplicity and consistency. By providing a simple 
building block that is extensible and can be flexibly 
combined with others, a great deal of modeling capability 
is provided without complicating the common simple cases. 
In this way, the critical operations and resources can be 
modeled in adequate detail while the non-critical models 
remain suitably inexpensive. 

A user may select an extension from the operation 
model type to, for example, define a transportation 
operation model. Alternately, a user may choose an 
extension from the operation model type that creates a 
smelting operation model for smelting iron ore to produce 
steel in a smelter. In essence, every act that needs to 
be performed by a process is modeled using the operation 
model type. 

An example of an extension for an operation model is 
a run extension. A simple run extension may consist of 
one field: the fixed amount of time that the operation 
model is to run. For example, a particular operation 
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that runs for 2 hours may be modeled by that extension. 
Alternatively, a more complicated run extension may have 
three fields: such as a load-run-unload. This extension 
may define a predetermined, constant time for loading 
5 material, followed by a run time which is a factor that 

is multiplied by the quantity of material that is being 
processed, followed by an unload run time which is 
constant. The load, run, and unload phases may each 
require use of different resources. 
10 Operation models represent activities that consume 

items, produce items, and/ or utilize capacity. Such 
operation models define the activities and precedence 
(timing) constraints in a process. 

In manufacturing, a sequence of operations is 
15 referred to as a routing. A routing is represented as an 

Operation model with a routing extension which defines 
the behavior of that operation to be a sequence of other 
:L operations. Similarly, the specification of alternate 

J resources, alternate operations, and alternate routings 

S 20 can be done with an operation model and an alternates 

*2 extension which defines the behavior of that operation to 

® be "perform one of these other operations". 

Additionally, an operation model may maintain constraints 
between successive operation models such as perish times 
25 (i.e. the maximum time between operations) . 

The Operation-Plan Model Type 

An operation-plan model type may be used to create 
operation-plan models which represent the plans to 
30 perform activities that are represented by operation 

models. The operation-plan model refers to an operation 
model that defines the allowed behavior. The operation- 
plan model represents a choice among the allowable 
behaviors, or even a choice of a disallowed behavior (an 
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infeasible plan) • For example, the operation-plan model 
would include the dates during which the operation will 
be performed. If different resources may be chosen to 
perform the activity, the operation model represents 
those options, whereas the operation-plan model 
represents a choice of the resource planned to be used. 

Extensions selected for the operation model can 
cause corresponding extensions to be selected for a 
operation-plan model that refers to the operation model. 
Those extensions add fields and semantics that correspond 
with the semantics of the operation model. For example, 
an extension may add minimum and maximum limits for a 
value in fields of the operation model, and a 
corresponding extension may add the planned value as a 
field of the operation-plan model. 

The Resource Model Type 

A resource model type may be used to create resource 
models which represent aspects of a process that have a 
predetermined capacity. For example, a resource model 
may represent laborers used in a manufacturing process. 
A resource model may represent a physical object such as 
a truck, a forklift, an oven, or any other object used in 
implementing the process that has a predetermined 
capacity limitation (such as space, electricity, or 
money) . 

The resource model type may provide various 
extensions from which a user may choose to define an 
actual capacity constraint on its process. For example, 
a simple extension may only have a single field setting a 
maximum capacity constraint. Such a resource model may, 
for example, represent a truck which has a maximum 
carrying capacity of 10 tons. Alternatively, a more 
complex extension may be chosen. For example, the 
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extension may have fields relating to both a maximum 
capacity and a minimum capacity. Extensions for the 
resource model type may also have fields for constraints 
such as the number of set up times allowed in a 
particular time period or the number of hours that may be 
devoted to setting up the particular resource. 

A resource model may have an efficiency extension 
that defines in one of a number of different ways how the 
efficiency of that resource varies over time. The 
efficiency may be defined as a fixed value, as a value 
that ramps up over time (a learning curve) , or as a value 
that changes seasonally as specified in a calendar. 

A resource model may have a variability extension 
that defines how the plan should be padded to compensate 
for the variability of that resource. A resource model 
may also have a maintenance extension that defines when 
maintenance is required. One extension may compute based 
on time since the last maintenance, the load-time during 
it, a weighted sum of load-times, the number of setups or 
the setup time, and other such times. It may also 
determine separately both major and minor maintenance 
needs • 

A resource model may have a size extension that 
defines the size of the resource and defines how the size 
is consumed by the various operations. For example, a 
truck trailer may have a size of up to ten tons and up to 
twelve feet high, eight feet wide, and 26 feet long. The 
resource would also know how to compute the weight and 
the physical dimensions of the operations that use the 
resource. A resource model may also have a load policy 
extension that defines the rules for loading that 
resource (e.g. no overlapping operations, and no 
operations longer than three hours on Mondays) . 
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Operation models may reserve capacity of 
predetermined resource models. For example, a user may 
define a transportation operation model for transporting 
an item. The transportation operation may reserve a 
truck resource model to carry out the act of transporting 
the item. 

An operation model may require more than one 
resource at a time. For example, in a milling process, a 
particular operation model may specify that it requires a 
milling machine resource model and a labor resource 
model. Additionally, an operation may reserve alternate 
resource models. Finally, a resource model may specify 
inter-operation constraints such as sequence-dependent 
set up times or combination constraints. For example, a 
resource model for an oven may specify that all 
operations that use the same temperature and are less in 
size than available space can use a particular oven at 
the same time. 

The resource model type can be used to model and 
manage a storage space. A storage space may represent, 
for example, a warehouse, a store room, a refrigerator, 
or floor space in a factory. 

The Resource-Plan Model Typ e 

A resource-plan model type may be used to create 
resource-plan models which represent the planned 
availability and usage of the capacity represented by 
resource models. The resource-plan model refers to a 
resource model which defines the allowed behavior. The 
resource-plan model represents a choice among the 
allowable behaviors, or even a choice of a disallowed 
behavior (an infeasible plan) • For example, the 
resource-plan model would include the dates during which 
the resource will run overtime. The resource model 
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represents the options for performing overtime, whereas 
the operation-plan model represents a choice of the 
overtime being planned. 

Extensions selected for the resource model can cause 
corresponding extensions to be selected for any resource- 
plan model that refers to the resource model. Those 
extensions add fields and semantics that correspond with 
the semantics of the resource model. For example, an 
extension may add minimum and maximum limits for a value 
in fields of the resource model, and a corresponding 
extension may add the planned value as a field of the 
resource-plan model. 

The Buffer Model Type 

The buffer model type is used to create buffer 
mpdels which manage items consumed and/ or produced in the 
modeled process. In other words, a buffer model 
represents the management of a particular item. The 
buffer model type may have extensions that represent 
constraints such as minimum and maximum inventory levels. 
Additionally, the buffer model type may have an extension 
that defines ordering policies such as lot-for-lot, or 
fixed size batches. A buffer model type extension may 
also require a "safety stock" that must be on hand at all 
times in case of emergency. 

A buffer model manages the flow of materials to and 
from an operation model. A buffer model may provide 
sheet metal to a press for stamping the sheet metal into 
a particular shape. As part of its definition, an 
operation model will point to the buffer models that it 
consumes items from and to the buffer models that it 
supplies items to. It is noted that a defined buffer 
model may not have an actual inventory associated with 
it. Rather, the defined buffer model may simply 
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represent an item flow control point. Alternative ly, a 
buffer model may maintain an inventory of items sitting 
between operations. 
The Buffer-Plan Model Ty pe 

A buffer-plan model type may be used to create 
buffer-plan models which represent the planned 
availability and usage of the capacity represented by 
buffer models. The buffer-plan model refers to a buffer 
model which defines the allowed behavior. The buffer- 
plan model represents a choice among the allowable 
behaviors, or even a choice of a disallowed behavior (an 
infeasible plan) . For example, the buffer-plan model 
would include the dates during which the buffer will run 
overtime. The buffer model represents the options for 
performing overtime, whereas the operation-plan model 
represents a choice of the overtime being planned. 

Extensions selected for the buffer model can cause 
corresponding extensions to be selected for any buffer- 
plan model that refers to buffer model. Those extensions 
add fields and semantics that correspond with the 
semantics of the buffer model. For example, an extension 
may and minimum and maximum limits for a value in fields 
of the buffer model, and a corresponding extension may 
add the planned value as a field of the buffer-plan 
model. 

Process Network Model 

FIGURE 1 is a graphical representation of a portion 
of a process network model indicated generally at 10 
according to the teachings of the present invention. A 
process network model is a set of user defined models 
which may be stored in a computer memory. The stored 
nodes define, for example, the user's factory which is to 
be used to manage a particular manufacturing process. A 
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user defines the process network model 10 of FIGURE 1 by 
selecting model types and the appropriate extensions of 
these model types, as described above, to form models of 
the elements of the users' process. The nodes in process 
network model 10 may be connected together in many 
different ways to achieve different results. Process 
network model 10 represents all of the possible 
interconnections between the user defined models. For 
example, process network model 10 of FIGURE 1, in part, 
consists of four operation models, 11, 12, 13, 14 and 15, 
and four buffer models, 16, 18, 20 and 22. Material may 
flow through various paths in process network model 10. 

Operation model 11 of FIGURE 1 may represent the act 
of stamping a piece of sheet metal into one of many 
different predetermined shapes as modeled by operation 
models 12, 13, 14 and 15. Additionally, buffer models 16 
and 18 may supply two different types of sheet metal. 
The portion of process network model 10 shown in FIGURE 1 
shows several alternative material flow paths. 

For example, sheet metal may be provided by buffer 
16 to operation 13 and then to buffer 20. Alternatively, 
sheet metal may be provided by buffer 16 to operation 14 
and then buffer 22. Sheet metal may be provided by 
buffer 18 to operation 14 and then to buffer 20. 
Alternatively, sheet metal may be provided by buffer 18 
to operation 15 and then buffer 22. 

Process network model 10 represents the possible 
routes that material may flow in a process to be modeled. 
The software system of the present invention uses the 
information in a process network model to create plans 
for implementing a particular material flow path to model 
a process. The interconnected nodes of the process 
network model used to represent a particular plan may be 
referred to as a plan network model or plan. 
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The software system of the present invention may 
create a plan network model as a result of several 
different events. In general, a plan network model 
provides definitions as to quantities and timing for 
elements of the model. For example, the inventory level 
for an item managed by a particular buffer model may drop 
below an allowable level. In response, the process 
network model may create a plan network model for 
replenishing the inventory of that buffer model. 
Alternatively, a plan may be created using the process 
network model in response to customer orders. 

The software system of the present invention may 
create a plan network model as follows. For each 
activity in a user's process, the software system creates 
an operation plan model from an operation-plan model type 
using extensions from the corresponding operation model. 
The system provides the operation plan model with the 
start and end dates, alternate selections, and other 
information needed to form a plan for a particular 
execution of that operation. 

For each resource model that is used by an operation 
plan, the software system creates a resource plan model 
from a resource-plan model type and the extensions 
corresponding to the resource model. The system provides 
the resource plan model with all of the capacity 
reservations placed on it by the operation plan models. 

For each buffer model from which items are consumed 
or to which items are supplied by an operation plan, the 
software system creates a buffer plan model from a 
buffer-plan model type and the extensions of a 
corresponding buffer model. The system provides the 
buffer plan model with inventory levels, ordering 
policies and any other information needed to plan the 
management of the flow of items in the process. The 
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various plan models interact to create a schedule of 
events to implement the modeled process to produce a 
selected quantity of output. 

5 Plan Network Model 

FIGURE 2 is a graphical representation of a plan 
network model for producing, for example, bicycle fenders 
in a predetermined process. For purposes of FIGURE 2, it 
is assumed that a user has previously defined a site 
10 network having all of the operation-plan, buffer-plan, 

and resource-plan models necessary to model the user's 
physical facilities and process requirements. In 
y3 response to a condition for creating a plan as identified 

^ above, each operation-plan, buffer-plan, and resource- 

Sj 15 plan model required for use in the plan creates plan 

« models. The flow of material through the manufacturing 

gpt process for creating bicycle tires as modeled by the 

s software system of the present invention is described in 

D 

detail below. 

£3 20 The storage space holding sheet metal for creating 

4; bicycle fenders is represented by resource-plan model 32. 

At operation-plan model 33, sheet metal from resource- 
plan model 32 is made available in buffer-plan model 34. 
Buffer-plan model 34 manages the flow of sheet metal. At 
25 operation-plan model 36, the sheet metal is stamped into 

a predetermined shape for the fender. Stamp operation- 
plan model 36 requires two resource-plan models. First, 
resource-plan model 38 comprises an industrial press with 
a die selected to press the sheet metal into a 
30 predetermined shape. It is noted that the die may be 

modeled as a separate resource. A second resource-plan 
model 40 for operation-plan model 36 may be a laborer 
that operates press resource-plan model 38. 
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Buffer-plan model 42 manages the flow of pressed 
sheet: metal from operation-plan model 36 to operation- 
plan model 44. At operation-plan model 44 , the pressed 
sheet metal is painted. Painting operation-plan model 44 
5 may use resource-plan models 46 and 48 such as a vat of 

paint and a laborer. 

The final step in preparing the fender is to dry the 
paint. Buffer-plan model 50 manages the flow of material 
from painting operation-plan model 44 to drying 

10 operation-plan model 52. Operation-plan model 52 

utilizes a resource-plan model 54 that may comprise an 
oven or other appropriate heating element to dry the 
paint. Heating resource-plan model 54 is operated by 
resource-plan model 56 which may represent a laborer. 

15 The dried fenders are pulled from buffer-plan model 60 

and stored in a storage space modeled by resource-plan 
model 58 by operation-plan model 57. 



§ Families 

□ 20 Nodes in the process and plan network models may be 

interrelated with common elements in a hierarchical order 
referred to as families. Each node can have only one 
family. In a family relationship, the children nodes 
inherit all the extension and field values of their 
25 family nodes unless they are specifically overridden by 

the child. Any changes to fields of a parent model are 
effective for the child models that do not override those 
fields. 

FIGURE 3 shows an example of the use of families for 
30 a resource model. Resource models 70 , 72 and 74 are all 

ovens. Resource model 70 is the family. Resource models 
72 and 74 are the children. Both resource model 72 and 
resource model 74 have all of the same extensions as 
resource model 70. Model 72 inherits all values from 
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model 70. Model 74 inherits all values except it has a 
larger size and higher efficiency. 

Use of families allows planning at different levels. 
In this example, the information stored at the node for 
resource model 70 may be used to perform aggregate 
planning. Whereas the information stored at the nodes 
for resource models 72 and 74 may be used to perform more 
detailed plans as to what particular ovens are to be used 
for particular operations. 

Date Effectivitv 

Families may be used to provide an efficient manner 
in which to update changes to a model. Date effective 
changes to a model generally affect only a small number 
of the total fields. It would be tedious and error-prone 
to have to maintain, for example, many independent copies 
of the same information in date effective variations. 
The principle of inheritance in families may be used to 
efficiently implement date effective changes to a model. 
As shown in FIGURE 3, gas oven resource model 78 is only 
valid until a specified day, DATE. Beginning on DATE, 
electric oven resource 80 must be implemented. A date 
effective field of resource 78 dictates that it may only 
be used prior to the DATE. After the DATE, only resource 
model 80 may be used. 

Although the present invention has been described in 
detail, it should be understood that various changes, 
substitutions and alternations can be made hereto without 
departing from the spirit and scope of the invention as 
defined by the appended claims. 
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